If a tool needed to unhook from a core in some way, it can do that in for example the setter method of [RequiredService] IEmulator _maybeCore. A separate Stop method would be redundant.

Wouldn't the old core already be disposed by the time that setter is called? (This would introduce additional complications if we have multiple services, but that's really an issue with using reflection which is another thing I intend to eventually fix.)
ToolManager.Restart does ServiceInjector.UpdateServices(_emulator.ServiceProvider, tool) then immediately after calls the tool's Restart method. So anything that can be done from a service property's setter could also be done in Restart (assuming the tool hasn't lost its reference to the old service). If we could access the old core from Restart, then there would not be any need for a Stop method.

You're trying to sculpt the tools' lifecycle, modelled on WinForms', into something that resembles a Lua script's lifecycle.

No I'm not. The tool's lifecycle isn't relevant here. We care about the core being disposed, not the tool.